\chapter{Environnement d'exécution}

\section{Aspect sécuritaire}

SPASS doit être capable d'exécuter des tests sur des programmes, quels qu'ils soient. Il est donc impératif d'avoir une notion de sécurité. Cette sécurité prend la forme d'un environnement d'éxécution sécurisé mis en place avant chaque exécution de module externe. 

\subsection{Environnement d'exécution des plugins}

\subsection{Environnement d'exécution des tests}

Tester un programme externe, parfois même au cours de son developpement, est une source d'erreur énorme pour le processus effectuant les tests. En l'occurence, il nous fallait un moyen d'éviter qu'un programme instable ou non terminé ne plante l'application lors d'un test. 
Le meilleur moyen nous semblait être de préparer un environnement d'execution séparé et différent du contexte d'execution de spass. Néanmoins, le principal problème venait du choix de ce contexte d'execution, nous ne pouvions nous permettre de créer un contexte trop spécifique ou trop large.
Afin de remédier à cela nous avons utilisés un mécanisme de "fixture.

\subsubsection{Gestion des fixtures}

Le mécanisme de fixture est relativement simple. Une fixture est un script initialisant l'environnement d'exécution que nous voulons utiliser.
Deux fixtures sont lancés, une très simple qui sera lancé automatiquement, et une autre liée a un test.
La première recopie les fichiers à tester dans le repertoire \/tmp. Cette fixture est lancée avant chaque test.
La seconde est écrite par l'enseignant pour chaque test. Ainsi, chaque test peut bénéficier d'un environnement d'exécution adapté sans avoir à tenir compte de conditions aprticulières liées au test suivant à exécuter.

\section{Robustesse}

Spass se doit d'être stable c'est pourquoi nous avons apporté un soin particulier à certains points.

\subsection{L'API}

L'API de spass est conçue pour avertir l'utilisateur au cas où une manoeuvre qui n'aboutie pas, ou portant sur des données inexistante, se produit. Le programme ne plante donc pas en milieu d'execution sans donner d'explications. Toutes les fonction de l'api possèdent une retour d'erreur afin que l'utilisateur puisse comprendre pourquoi sa demande n'a pas put aboutir. 

\subsection{Module error}

\subsection{Terminaison maitrisée}

